ci: cut releases automatically so merged deploy/ state reaches the cluster#62
Merged
Conversation
…uster The github-config tenant on the platform cluster syncs the org's declarative GitHub state from a cosign-signed OCI artifact that cd.yaml publishes only on v* tags. Nothing cut those tags on merge to main, so every deploy/ change since the last hand-cut tag (v1.4.2, 2026-06-18) — the maintainers team (#50), issue labels (#57) and repository discoverability metadata (#60) — was validated, merged, and then never delivered: the OCIRepository is still pinned at 1.4.2 and no Team/IssueLabel CRs exist on the cluster. Add the standard release pipeline every other devantler-tech repo already has: a Release workflow that runs create-release.yaml (semantic-release) on push to main, plus a minimal .releaserc. semantic-release cuts the v* tag, which triggers cd.yaml to publish the OCI artifact, which the tenant reconciles. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
devantler
added a commit
that referenced
this pull request
Jun 23, 2026
PR #50 inadvertently removed external-secret.yaml and provider-config.yaml from deploy/kustomization.yaml's resources, so the github-config OCI artifact no longer ships the credential ExternalSecret or the ProviderConfig. The break stayed latent while the tenant OCIRepository was pinned at v1.4.2 (which still carried them); #62's auto-release cut v1.5.0 from current main, and the prune on apply deleted the ExternalSecret and started terminating the ProviderConfig -> github-app-credentials is gone -> every Repository/IssueLabels/Team managed resource fails to connect (Synced=False, ReconcileError: credentials secret github-app-credentials not found). Restore both entries (with a guard comment) so the artifact materializes the credential again and the declarative GitHub state reconciles. Co-authored-by: devantler <devantler@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem — merged
deploy/state never reaches the clusterThe
github-configtenant on the platform cluster syncs the org's declarative GitHub state from a cosign-signed OCI artifact (oci://ghcr.io/devantler-tech/github-config/manifests,semver: ">=1.0.0"). That artifact is published bycd.yaml, which runs only onpush: tags: v*.ci.yamlonly validates PRs; nothing in the repo cuts av*tag on merge tomain.The last tags (v1.4.0–v1.4.2, 2026-06-18) were hand-cut by the maintainer during the initial rollout. Since then three
deploy/PRs merged but no tag was cut, so none of them are live:feat(deploy):maintainersteam + 12TeamRepositorybindingsTeam/TeamRepository→No resources foundfeat(deploy):IssueLabelsacross all reposIssueLabels→No resources foundchore(repositories):Live evidence: the
github-configOCIRepositoryis still on1.4.2@sha256:293cbda…;RepositoryCRs are allTrue/True(provider healthy) butkubectl get teams,teamrepositories,issuelabels -Areturns nothing. So the declarative-GitHub GitOps path is broken end-to-end after merge — exactly the "manage GitHub declaratively" guarantee #57/#50 were meant to deliver.Fix — the standard release pipeline every other repo already has
Add a
Releaseworkflow that runs the sharedcreate-release.yaml(semantic-release) on push tomain, plus a minimal.releaserc(@semantic-release/commit-analyzeronly). semantic-release cuts thev*tag →cd.yamlpublishes the OCI artifact → the tenant reconciles. This is byte-identical in structure togo-template'srelease.yaml+.releaserc(the canonical template; its releases are auto-cut bygithub-actions[bot]), differing only in the pinned reusable-workflow SHA (latestv5.6.6).Once this merges, the first run analyzes commits since
v1.4.2— which include #50 and #57 (feat:) — so it cuts v1.5.0 and delivers the whole backlog at once. That includes #57'sIssueLabels, which are authoritative (they remove any labels not in the declarative set). That is the intended behavior of #57, surfaced here so the first reconcile is no surprise.Design question for the promoter
If
.githubreleases were intentionally kept manual to gate when sensitive org-state reconciles, close this. The evidence (3 PRs / 5 days of silent, unintended drift; every other repo auto-releases; no documented manual-gating intent) says this is a gap, not a design choice — but the promotion is your call.Validation
kubectl kustomize deploy/— OK (unchanged; this PR adds no manifests).release.yamlYAML valid; structurally identical togo-template's working workflow..releasercvalid JSON, mirrorsgo-template.